【小ネタ】Amazon RDSの汎用（SSD）ボリュームに負荷をかけてBurstBalanceメトリクスの挙動を見てみた

#Amazon RDS

#AWS

きうち

2017.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、城内です。今回は、最近ちょこちょこ確認することがある、RDSのディスクI/Oに関して、小ネタをはさみたいと思います。

やってみた

Web系のシステムで画面表示が遅いなどの障害に出会った時、ボトルネックを探るためWebサーバやDBサーバのリソース状況を確認するかと思います。 1つ1つ確認していけばある程度は当たりがつくものですが、最近、DBサーバのディスクI/Oがボトルネックであるケースにあたりました。

AWSではこれは結構あることかと思いますが、汎用（SSD）ボリューム（GP2）が標準的に使われるようになった今、割とボリュームサイズが小さめだったりで思った程パフォーマンスが出ていない、なんてことありませんか？実は結構なディスクI/Oが発生しているのに、長時間の処理を動かしたことがなく、バーストでギリギリ乗り切っていた、なんてケースでは意外と気づかないものだったりするかと思います。

そんなこんなで調査をしながら、以下のような記事を読んでいたら、

なんと、CloudWatchのRDSのメトリクスにもBurstBalanceがあるじゃないですか！？

ただ、CloudWatchのドキュメントには記載がなかったので、正確にEBSのBurstBalanceと同じものかどうかは判断がつきませんでした。

Amazon RDS のメトリクスとディメンション - Amazon CloudWatch

ということで、じゃあ、実際に動かして挙動を見てみよう、と、RDSにディスクI/Oの負荷をかけてみました。

環境は以下の通りです。

エンジン：MySQL 5.6.35 インスタンスクラス：db.m4.large ストレージタイプ：汎用（SSD）ストレージサイズ：100GB

MySQLでの負荷テストツールは、標準のmysqlslapを使いました。以下のようなコマンドで、パラメータをちょこちょこ変えながら、どこまで高負荷をかけられるかなと実行していました。

$ mysqlslap \
>  --no-defaults --auto-generate-sql --engine=innodb --auto-generate-sql-add-autoincrement \
>  --host=mysqldb.abcdef123456.ap-northeast-1.rds.amazonaws.com --port=3306 --user=dbadmin --password=xxxxxxxx \
>  --number-int-cols=10 \
>  --number-char-cols=10 \
>  --iterations=50 \
>  --concurrency=5 \
>  --auto-generate-sql-write-number=3000 \
>  --number-of-queries=100000 \
>  --auto-generate-sql-load-type=write

結果、以下のようになりました。